What was changed

When debug_mode=True on the Worker (or TEMPORAL_DEBUG=1), breakpoint() inside workflow code now opens an interactive pdb prompt — including from a sandboxed workflow run under pytest. Without debug_mode, the sandbox raises a clear error pointing the user at debug_mode=True. Pieces:

• Inline dispatch on the main thread (debug mode). In debug_mode, activations run on the asyncio main thread (scheduled via loop.call_soon to avoid nesting inside the dispatch task's __step()), so pdb's input() reaches the TTY.
• Targeted sandbox relaxation (debug mode). In debug_mode, breakpoint is removed from the sandbox's invalid builtins so the call can reach the worker hook. Nothing else is relaxed.
• Custom Pdb subclass. Drops into pdb at the workflow's own frame (not our indirection), suspends sandbox checks for the duration of each REPL interaction, and overrides q / Ctrl-D to continue the workflow instead of failing it with BdbQuit.
• Better sandbox error without debug_mode. The sandbox's breakpoint restriction now carries a leaf_message directing the user at debug_mode=True (rather than the generic "mark the import as pass through" advice, which is the wrong fix here). Uses the same SandboxMatcher.leaf_message mechanism already in place for asyncio.as_completed.

The workflow sys.breakpointhook is only installed when debug_mode=True. With debug_mode off, dispatch, sandbox config, and sys.breakpointhook are all identical to upstream main.

Why?

breakpoint() and pdb.set_trace() inside workflow code can't reach a debugger today. In a sandboxed workflow, the sandbox raises an error — but the error tells the user to "mark the import as pass through," which is the wrong fix. In an unsandboxed workflow, the call falls into pdb on a thread without a working stdin and the worker thread hangs.

Three overlapping issues for the debug-mode path:

1. Activations run on a ThreadPoolExecutor thread, so pdb's input() can't read the controlling TTY.
2. The sandbox flags breakpoint as non-deterministic, so the call can't reach the debugger.
3. pdb's cmdloop touches more sandbox-restricted internals at runtime (e.g. readline.get_completer) — relaxing the builtin alone isn't enough.

Direct synchronous activation from the dispatch coroutine doesn't work on Python 3.14:

RuntimeError: Cannot enter into task <workflow run task>
  while another task <_handle_activation> is being executed.

The dispatch task is mid-__step() when workflow.activate tries to step the workflow's own task; 3.14 refuses. await future after loop.call_soon suspends the dispatch task first.

Complements #1249 (sandbox passthrough for IDE debuggers). Independent change, different debugger.

Checklist

1. Closes Setting debug_mode in a Worker still doesn't allow the user of breakpoints #1104

2. How was this tested:

• tests/worker/test_breakpoint_hang.py — five tests covering thread placement (both modes), breakpoint in a sandboxed workflow lands at the user's frame with locals visible, q/Ctrl-D continues cleanly, and (without debug_mode) the sandbox error message points at debug_mode=True. 5/5 pass on Python 3.13 and 3.14.
• Manual: drop breakpoint() into any workflow's run() body, run via pytest -s (or a standalone python script), confirm the (Pdb) prompt opens at the user's frame with locals in scope.

3. Any docs updates needed?

• Yes. Adds a "Debugging Workflows with breakpoint() / pdb" subsection to the README under Workflow Sandbox, with a runnable example and the workflow-task-timeout caveat.